接續昨天內容，為什麼購物車要分成主體跟項目呢？
主要有幾個原因，首先是因為擴充性比較好，再來是常用的異動功能所需，
簡單來說就是不屬於任何一個商品項目的內容，需要儲存的話，
就有主體跟項目結構的必要，今天用異動通知作為範例，
也讓大家透過實際情況了解其中原因。

先說明一下情境，購物車的項目因為沒有馬上購買，
所以在後台有異動的時候需要通知使用者，其中異動主要分為更新及刪除，
更新可能為修改商品名稱、商品敘述或者商金金額等，
對於金錢或者商品敘述比較重要的，刪除可能為下架或者真實刪除，
這時候就要提醒使用者說明商品有資料異動，

搭配基礎結構新增欄位

// 購物車主體
Schema::create('cart', function (Blueprint $table) {
    $table->string('member_id', 30)->comment('會員id');
    $table->boolean('change')->default(0)->comment('是否異動'); 
    $table->primary(['member_id']);
});

// 購物車項目
Schema::create('cart_item', function (Blueprint $table) {
    $table->string('id', 30)->comment('項目id');
    $table->string('cart_id', 30);
    $table->string('product_id', 30);
    $table->integer('quantity'); // 數量
    $table->boolean('change')->default(0)->comment('是否異動');
    $table->primary(['id']);
    $table->index(['cart_id']);
    $table->index(['product_id']);
});

可以看到兩個table都新增了change欄位紀錄是否異動，
因為假設異動的項目是刪除，又因為cart_item也會一同刪除，
這時候沒有辦法更新change，所以會需要主體的change欄位。

最後程式在抓到購物車資料後，判斷兩張表裡面change如果有任何一項不為0(沒異動)，
就通知使用者說商品資料有異動，這樣就達成我們的目的。

以上算是最簡單的異動通知，其實還有很多處理方式，
例如鎖定舊資料並提醒刪除，或者對於修改欄位顯示異動前後的差異，
但相對整體結構就會複雜很多，依照一般小專案的預算幾乎不太可能做到該規模，
因此這邊就大概提一下，大家知道還有很多處理方式就好。